JAWS-UGコンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念! に参加しました #jawsug_ct
はじめに
皆さんこんにちは。石橋です。
6/24に行われた「JAWS-UGコンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念!」の参加レポートを書かせていただきます。
JAWS-UGコンテナ支部 #17 ECS/Fargate PV 1.4 ローンチ記念！ | connpass
Black Belt Online Seminar "Container Service Update"
今回は、イベント同日18:00 ~ 19:00に2020年上半期のコンテナサービスの新機能やアップデートを振り返るBlack Belt ウェビナーの放送がありました。 イベントの前座として、この時間帯にコンテナ支部の運営の方も同ウェビナーを見ながら、アップデートに対する雑談がtwitter上で行われました。(ハッシュタグは #jawsug_ct #awsblackbelt)
以下のブログもあわせて参考にしてください。
セッション
コンテナとコンテナのつなぎかた on ECS
登壇者
- 林 政利 / Specialist Solutions Architect, Containers / Amazon Web Services Japan
- twitter: @literalice
セッション概要
コンテナをECSにデプロイしたら、その機能を他のコンテナから呼び出したくなりますよね。ELBにコンテナを関連付けて呼び出すのもありですが、他にも様々な方法があるようです。 このセッションでは、Service DiscoveryやAmazon EventBridge、AWS Step Functionsなどに触れながら、コンテナ間をどう繋ぐか考えてみたいと思います。
セッションレポート
- セッションの目的
- Amazon ECSにおけるコンテナとコンテナのつなぎかたを整理する
- ３種類のコンテナの連携方法 「タスク内接続」「サービス間接続」「イベント駆動連携」がある
- タスク内コンテナ接続
- サイドカー、アンバサダー、アダプター
- 業務と関係ない機能を別コンテナに切り出し、アプリコンテナを純粋に保つ
- ネットワーク空間やストレージを共有して密な連携ができる
- サービス間接続
- なぜサービスを分けて、お互いを接続したいのか再考する
- インテグレーション時に問題が発生するタイミング
- ライブラリを更新したら壊れた。Fargateに移行したい。など。
- インテグレーションの差が大きく調整に時間がかかる
- サービス間の接続は、このインテグレーション問題の解決のアプローチ
- コンテナ接続のあまり良くないパターン
- コンテナの内部実装に暗黙的に依存
- DBスキーマ共有など
- インテグレーションが絞れていないケース
- 一般的なサービス間の接続
- ドキュメント化されたAPIで接続
- サービス内の実装に依存しない
- ポータビリティ性の高い環境ではサービスディスカバリーが利用される
- サービス間接続のパターン
- Amazon ECS Service Discovery
- サービス同士をAPIでつなぐ
- ヘルスチェックが通ったらサービス同録
- Cloud MapというAWSリソース全体を管理できるService Discoveryを使っているということがポイント
- AWS App Mechによるサービス間通信レイヤーの導入
- 独立性のサービス同士を統一した方法でつなぎたい
- App Mechにレイヤーで通信方法を設定
- リトライ、タイムアウト、通信先の切り替え、X-Rayによる可視性の確保
- 「サービスそのもの(実態)」と「通信の仕様」を切り離すことができる
- イベント駆動連携のパターン
- イベント駆動連携により独立性を高める例
- Amazon EventBridge & Amazon SQSを用いるパターン
- Amazon SNS & Amazon SQSを用いるパターン
- Amazon Kinesis Data Streamsを用いるパターン
- イベント駆動連携は、依存関係が課題になりやすい
- AWS Step Functionsで依存関係を整理する
- サービス間の処理の流れが明示的
- 依存関係の管理をStep Functionsに移譲することで、各サービスの独立性が高まる
- あるステップを他の実装に差し替えるということがやりやすい
- まとめ
- なるべくシンプルな方法でつなぐ
- 必要に応じて様々なパターンを検討する
- サービスの独立性を保ち、パターンを検討できる状態にしておく
感想
コンテナとコンテナの繋ぎ方について、その方法とユースケースやメリットおりまぜて分かりやすくお話して頂けました。ユースケースに合わせてコンテナの繋ぎ方を使い分けていきたいですね。
金融系サービスでECS/Fargateを設計するということ
登壇者
セッション概要
金融系と聞くと、「信頼性とセキュリティ最重要だ」と考えられる方もいるのではないでしょうか？そのような中で挑戦的にも金融系サービスでECS/Fargateを採用したお話をご紹介します。 どのような背景からECS/Fargateを採用したのか、そして実稼働に至るまでにどのような考慮が必要だったのか、共有していきます。 これからECS/Fargate利用を検討されている金融以外の方にも、設計のお力になれるような発表にしたいと思います！
セッション資料
セッションレポート
- 金融サービスの変化
- 安定性・セキュリティ・ガバナンスのどれか一つが欠けると、途端に信頼を失うのが金融系サービスの宿命
- 法改正やFinTech企業が登場し、金融サービスが拡張されてきており、"金融"という括りの扱いが変わってきている
- ECS/Fargateという選択
- FinTechイノベーション領域ではユーザーファーストな対応が重要。「堅牢性 < 新しい体験・利便性」
- ユーザー価値 = ビジネス価値 => ビジネス価値へのコミットに注力
- ユーザー価値向上にリソースを集中し、「一定の品質維持」と「無駄な努力の削減」をしたい
- コンテナによる解決(開発の効率化、安定した稼働環境)
- AWSでコンテナなを採用する際の選択肢(コントロールプレーン(ECS or EKS) x データブレーン(EC2 or Fargate))のどれを選ぶ？
- データプレーン => Fargateを採用
- ユーザー価値向上にリソースを集中したい。運用・保守作業をなるべく減らしたい => マネージドサービスを使いたい
- コントロールプレーン => ECSを採用
- いくつかの理由でEKSの利用を見送った
- 導入当初はEKSとFargateで組み合わせが選択不可
- 初期学習コストが高かった
- 早いアップデートサイクスに耐えたれる運用チームが組成されていなかった
- スモールスタートで始めるにはECSの機能で十分と判断できた
- 設計に必要な視点の整理
- ECS/Fargate利用であっても、安全性・セキュリティ・ガバナンスを充足しなければならない
- 金融システムとして堅牢性を支えるFISC安全対策基準への遵守
- クラウドに寄り添った設計・運用を心がけるためのWell-Archtected Frameworkの金融サービスに特化したレンズ
- ECS/Fargate設計の要所
- NWトラフィックを可能な限りプライベートに保つことを検討する
- VPCエンドポイントを配置することでプライベートネットワークに閉じる
- インターフェイス型のエンドポイントはコストが膨らみやすい => コストとのバランス
- アプリケーションのクレデンシャル情報の保護に気をつかう
- タスク定義ないで環境変数として受け取る
- Secrets ManagerへのアクセスはIAM最小権限
- アプリクレデンシャルは暗号化して保存
- 補足
- Fargate v1.4.0からはプライベートサブネットでタスクが稼働する場合、SecretsManagerのインターフェース型VPCエンドポイントが必須
- コンテナ構成のフローを丁寧に定義する
- CI/CDのパイプラインにてリスクを排除する
- ビルドのステージ最小限のコンテナイメージを作成する
- 既定パイプラインでのみビルド&デプロイを行う
- プライベートなリポジトリを仕様する
- サードパーティ製の脆弱性スキャンを有効化する
- データ保存箇所を俯瞰して保護レベルを検討する
- パイプラインで作成されるS3バケットに対するIAMユーザー等による直アクセス・パブリックアクセスを禁止し、監査視点でのオブジェクトロックを検討をする
- ECRのPushをCodeBuildからのみ許可する。戻しなどに備えてタグにより履歴を保存する
- マネージドな部分の仕様を理解した設計を行う
- Fargateのリタイア(AWS管理のハードウェア障害やセキュリティ脆弱性に対するパッチの適用に伴うタスク置き換え)を考慮する
- リタイアの原因はHW障害がほとんどなので、マルチAZ化により業務継続が可能
- 30秒タイムアウト後にSIGKILLシグナル送信
- まとめ
- ボトムアップな設計観点からは金融サービスのみならず、ECS/Fargate利用時の参考になるのでは
- 比較的、遵守事項が多く厳しい金融基準の視点でみることで、よりセキュアかつ安定したAWSコンテナ利用が可能になる
感想
金融サービスにおけるFargateの利用例として、大変参考になるセッションでした。個人的にW-Aのレンズを知らなかったので、これからは設計の際の指標にしていきたいと思います。
FargateでService、Cron、RunTask基盤を運用する
登壇者
- Shohei Koyama / Timee, Inc.
- twitter: @sion_cojp
セッション概要
タイミーではFargateを利用してService（rails server）, Cron, Runtask（どちらもrake task）を利用しております。 実際どのように運用しているかお話をさせて頂きます
セッション資料
セッションレポート
- 実際の運用テクニック
- 管理方法
- terraform
- 使う基盤を共通化。シンプルな設計。スケールを簡単にできるようにする
- アーキテクチャ図の保存
- 新しく参入する人が理解しやすいように図は必ず作る
- drawioで書いて.drawio .pngファイルで保存。必要なときに改修
- チュートリアル
- sandboxで誰もが気軽に作成できるようになっている
- 実際のコードを見るより動かしてみた方がわかりやすいため
- 共通化
- terraform moduleで共通化
- 変化が多いところは別のソリューションを考える
- タイミーでは、共通化が進んでおり、新規サービスを追加する際でもDockerfileさえあればすぐ共通化が可能
- Deploy
- ecs-deployという内製ツールを使用
- サービス側で用意されたMakefileにecs-deployを使ったdeployロジックが書かれている
- 権限さえあればローカルで実行可能なMakefile
- それをslack-deployというサーバ(Go)を経由して、slack経由で実行
- メンテナンス
- slack-deployからメンテナンスモードにできる
- Service
- ALBに対して２種類のlistenerルールを切り替える
- Cron
- 指定したもの or 全てを disable / enable にすることができる
- ロギング
- Fargate (firelens) => fluent-bit
- ecs-deploy側で環境変数をいい感じにセット
- detadog logsのタグによる検索製向上
- モニタリング
- Serviceのモニタリング
- ecs-update-notify(Goのツール)
- タスクが完全に切り替わった時の通知
- タスクが切り替わらなった時のエラー通知
- それ以外はDatadogで管理
- RunTask, Cron
- clusterに紐づいたLambdaで、exit 0以外の場合は指定したSlack Webhook URLに通知
- Lambdaからdatadogに実行にかかった時間(スタート〜ストップ)を飛ばす
- 最後に
- Fargateはとても便利で、タイミーではとても便利に有効活用している
- 実際に効率よく運用するのは大変。設計にはとてもセンスが必要
- 解決するためのソフトウェア開発能力も大事
感想
SlackでのChatOpsが高いレベルで実装されていて感動しました。Fargateは便利だけど、「効率よく運用するんはにセンスが必要」という言葉はとても胸に刺さりました。アーキテクチャ図の管理やチュートリアルが用意されていて、新しく参入してくる人のオンボーディングを助ける仕組みが整っている点も参考になりました。
ホスティングサービスのインフラ環境を再構築！〜AWS Fargateのおかげで幸せになれた話〜
登壇者
- Takayuki Yoshioka / ファーエンドテクノロジー（株）
- twitter: @yoshioka_cb
セッション概要
ホスティングサービスとして提供中のRedmine（Rails）のインフラ環境をFargateを利用して再構築しました。主に以下の話題を中心に知見をお伝えしたいと思います。
- 既存のモノリシックなシステムをどのように移行したのか？（再構築時の苦労話と解決策）
- Fargateで再構築後、運用時にどのような変化が生まれたのか？（Fargateのメリット、デメリット）
- その他、運用を自動化するために使用したサービスの紹介（CodePipeline, StepFunctionsなど）
セッション資料
レポート
- 構築
- MY REDMINE
- Redmineのホスティングサービス(SaaS)
- RedMicaとして提供中
- サービス選定の方針
- 運用コストを減らしたい => マネージドサービス中心で構築する
- 構成図の紹介
- Before: EC2メイン
- After: WebサーバーをFargate on ECS、Bastion(EC2)、設定ファイル用のS3
- 再構築のポイント(苦労した点)
- Redmine(Rails)のコンテナ化
- 永続化が必要なデータに対する対応
- DB
- RDS Aurora PostgreSQL互換エディション
- ログ
- Sidecar Patternでログ収集コンテナ(fluentd)を使用してログの収集
- 添付ファイル(一番悩んだ)
- 添付ファイルの保存先をS3にできるPluginを開発( redmica_s3 )
- マルチテナントについて
- ユーザーごとにECS Service起動=>コストメリットがない=>却下
- Apartment(ホストごとに接続DBを変えるGem)=>migrataion関連が辛い=>却下
- Apache + Passengerでプロセスごとにポートを切り替え。Apacheの設定ファイルはS3に保存
- ECSの選定理由。なぜEKSじゃないか。
- 当時EKSが東京で利用できなかった
- クラスターの料金が高かった
- Fargateの選定理由。
- EC2の管理、リソースの計算が面倒
- Fargateは管理コストが低い
- サーバーに入れないことは、調査範囲を限定できるという点ではメリット
- ECSに慣れないうちは、Fargateと同時にEC2も起動して様子をみる
- 運用
- CodePipeline
- GirLabからCodeCommmitにミラーリング
- Step Functions
- サービスアカウントの新規登録
- サービスアカウントの変更
- サービス停止、データ削除
- Migrationの実施方法
- rails db:migrateをどのように実行するか
- 当初はパイプラインにmigrationフローを入れていた
- S3からサイトごとの設定情報を取得し、Step Functionsの並列処理でサイトの数だけmigratehionをする
感想
Rails のマイグレーション周りに関する知見とマルチテナントに関する知見がたくさんあり、参考になりました。
まとめ
Black BeltのContainer Updateから、コンテナ同士の繋ぎ方、金融サービスでのFargate利用、タイミーさん・ファーエンドテクノロジーさんでのFargate利用事例と盛り沢山の内容でした。これらの知見を活かして幸せなコンテナライフを送れるようにもっと勉強しようと思った石橋でした。JAWS-UGコンテナ支部の次の回も皆さん楽しみに待ちましょう!!
